如果我们回到2005年，我们所交付的软件基本长这个样子：一个框架、一个数据库，也许有一些OLTP的过程来支持报表功能。那个时候，Web2.0是当时的Buzz Word，jQuery还非常时尚。每半年或者一年，有一个发布的流程把这样的一个软件包部署在几台Server上。
今天，这样的软件系统依然存在着，然而，下面这幅图所展现的才是一个更加典型的软件系统。我相信在这幅图里，一定有什么东西已经不复存在了，因为每隔几个月，就会有新东西出现。ThoughtWorks技术雷达是从2011年开始发布的，我记得当时的雷达上只有30多个blip，然而看看今天的技术雷达，这个数字已经上升到了足足100多。
这产生了一个非常有趣的趋势，使用每一个具体的技术来构建应用变得越来越容易，然而具体的技术本身的生命周期却越来越短，这导致了整体复杂度的上升，而这种新的复杂度，带来了与以往不同的挑战。
引入新的技术，有时会带来新的做事方法，有时会带来结构上的冲击；整体复杂度升高，带来的另一个问题是决策点越来越多，在不断变化的技术选择中做出决策是另一个挑战；由于技术的生命周期越来越短，技术会以更快的速度过时，如何从这样的遗留系统中走出来也是一个挑战。
有意思的是，这样的挑战，在我们经历过的长期项目上，都有非常明显的体现。
我们与A记之间的故事是从2010年底开始的，那时候，所有的团队在本地做构建，然后把RPM包发给运维团队，运维团队把RPM包部署到数据中心里去，部署过程基本上是手动完成的，开发团队与运维团队完全分离。
当时，虽然“持续交付”的概念已经提出来了，然而市场上并没有特别成熟的工具支持，有一次为了做个集成测试，整整花了3个月才把环境准备好。这个过程实在是太痛苦了，于是在2011年初，我们的一个团队开始用puppet/chef和shell脚本构建持续部署流水线，其实也就是两个人。也是因为看到了自动化的价值，于是A记开始评估是不是要上AWS。
从2012年到2013年，AWS来了，每个人点几个按钮就能申请一台机器，于是突然间，每个团队都开始构建自己的自动化部署能力，持续集成流水线的产物，也从RPM变成了AMI，而这种技术的采用导致了一个很有意思的现象。因为大多数的部署步骤全都嵌入到了持续集成流水线里，维持一个臃肿的运维团队就变的完全没有必要了。于是为了更好的推广自动化能力，每个开发团队“嵌入”了一个运维，与开发团队一起自动化部署流程。发布的流程也变的非常简单，只有两个人负责所有团队的发布工作。
到了2014年，终于A记几乎将所有的系统全都迁移到AWS上了，几乎所有的团队都开始使用CloudFormation来管理基础设施。这又导致了一个很有意思的现象，因为环境准备和部署的流程通过更成熟的工具完全自动化了，软件的发布变成了一次按钮点击，一个中心化的发布过程也变得没有必要了，这个责任就“去中心化”的落到了每一个团队自己的头上。
“Who builds it, who runs it. ”这样的理念催生了更加自治的团队，创造出了更强的响应力和责任感。开发们开始自发地用更加标准的方式来写log、更加关注系统的监控、更自主的诊断线上问题。于是发布周期大幅缩短，从月度发布到每周都能发布。再加上微服务架构的采用，让团队的结构再一次发生了变化。
团队变的更小，运维完全本地化到了团队里，开始一起做story。跨团队的知识共享由一个个的虚拟团队负责，这种spotify的团队结构，一方面把权责都交给了开发团队从而减少组织摩擦；另一方面，实践与治理的方案也更多的作为上下文跨团队进行分享，而不是自上而下的推进执行。
从2015年到2016年，Docker来了。除了大幅提升打包和部署的速度之外，更重要的是，开发与生产环境之间的不同进一步被消弥，部署的编程模型变的更加简单，而这为标准化部署方式提供了机会。A记的架构组推出了一个基于docker的工具，基于提供了的抽象层，把部署相关的实践和工具全都抽离到了开发过程之外。
于是，开发团队只需要专注于开发cloud-native的应用，部署相关的过程全都交给了统一的工具来处理。之后的效果是显著的，从2015年到2016年，AWS上服务的个数增长迎来了巅峰，A记也终于做到了随时都能部署，新的功能几分钟就能上生产环境。
我们与A记之间故事的明线是团队结构的不断变化，然而背后的暗线，却是技术趋势以及所带来的影响。在采用新技术的同时，调整团队结构，给予团队更大的自治，从而释放生产力，这是高效交付的秘诀。
故事依然还在继续，总是有新的挑战在前方。因为市场的压力，A记一方面需要进一步通过标准化来降低成本，另一方面，也需要拓宽自己的产品范围来赢取更多新的客户。这个挑战是所有成功的公司都正在面临的。
在新一期的ThoughtWorks技术雷达里，提出了“The Rise of Platform”这样的概念，每个成功的互联网公司都有一个基础平台来更好支撑和实施自己的业务战略，这正是现在A记想要前去的方向。而平台思维的关键并不是如何吸引开发人员，更多的是把开发者当作平台的客户，专注在如何提升开发团队的体验、关注在如何打造一个平台来为开发团队提供更多的自治，从而释放出更大的生产力。
随着开发团队有了越来越大的自治权，随之而来的是更大的责任，如何保证这种力量发挥在正确的地方，就是下一个故事了。
iPhone用户赞赏专用二维码
点击【阅读原文】可至洞见网站查看原文&绿色字体部分的相关链接。
本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。